I'm pleased to say that I have joined the Debian FTPTeam as of the Friday before last. See Joerg Jaspert's announcement on debian-devel-announce.

The FTPTeam is responsible for maintaining the Debian software archive, and ensures that new software in Debian is high-quality and compliant with our policies.

As an "ftpassistant", I (along with Paul, Scott, Gergely, and others) will be helping to process the NEW queue, which is currently at a whopping 297 packages. Here's hoping we'll be able to get that number down over the coming weeks!

Wohoo, one more in that little series of mine, another update to tm. This time it gained getopts style options - while retaining the old non-getopts style. It now can open more than one multisession to the same set of hosts, so you can connect multiple times to host1 host2 at the same time. No matter if you open them using the ms subcommand or the pre-defined sessions from the .tmux.d directory. I also took a bit and wrote some zsh completion for it. I m pretty sure this can be done better and am happy for patches, but it does work for me, so for now I m happy. You can, as usual, grab tm from my misc git repository, the zsh completion is in my zsh config repository - also at Github.

There was Lenny, there was Squeeze, now there is Wheezy. Another major release of Debian where I had the pleasure to do the ftpmaster work for the release. Like the last times, Mark joined to help with the work. But 2 FTPMasters aren t enough for one Wheezy, or so, so Ansgar had his first run aside from point releases. With the whole load of work the release team did in the past to prepare this, combined with all the changes in dak we had since Squeeze, it turned out to be rather easy for us. Again, a few moments and not a detailed log (times in CEST):

• [10:45] Let s prepare. Cronjobs go off on ftp-master and security, shared tmux session setup, including a live pipe into a file so other team members can follow using less +F -R , a titanpad page opened to share in writing the commands to process later.
• [11:18] One last package update done manually. The latest and greatest of installation-guide, 20130503, really wants to join the rest in wheezy.
• [12:00] While I did a database backup and started preparing the set of commands for later, Mark and Ansgar prepared our code to deal with the changes we are about to make.
• [12:33] I start executing the commands (shell and sql), so somewhen after here we have Squeeze as oldstable (with all its extra suites also renamed), Wheezy as stable (taking its own suites with it, as well as gaining the -updates). And Jessie starts its life.
• [12:45] Heissa, wouldn t be fun if we wouldn t have some bugs, so we just created a load of directories not needed or wanted. Not getting Jessies either. Ohwell.
• [13:00] Jessie gets a copy of Wheezy to start with. Made the mistake to try that with our usual tool, control-suite. Err. Wrong. This is doing a set of checks on each package inserted. Would take ages. While one SQL to bypass the checks was a minute or so.
• [13:xx] Got annoyed by our concept of consistency. Its great. Every tool takes suite names/codenames in a different way. Seperated with spaces, with commas, with codenames, with suitenames, we mix it in all possible combinations.
• [14:00] Ansgar finished updating our security master host to cope with the changes for the release.
• [14:39] Squeeze Release files got regenerated and signed again.
• [14:54] Wheezy Release files got generated and signed.
• [15:05] The cd build machine has a synced mirror tree, so they can start building our CD/DVD images
• [16:25] A manual dinstall finished. And while it had some small problems (including nearly overwriting something inside the wheezy dists/ tree), it went pretty smoothly.
• [21:00] After having kept the archive turned off for the whole day, we have 90 uploads with ~3Gb of uploads waiting. As it is now unlikely that we need larger archive changes, we turn (most of) our cronjobs back on, to get them processed.

Right now (that is, 21:08 CEST) I am mostly waiting for the CD build to finish. Current schedule seems to have that in some two and a half hours, after which we can push the mirrors and our press people announce it. Except if Murphy wants to show up, but lets hope that not. Thanks go out to everyone involved in preparing this release, be it in the past by fixing bugs, uploading packages, doing whatever was needed, as well as doing the work today.

Just did a small update to my tm helper script. There is now a new variable, TMSESSHOST. If that is set to false, the hostname of the current machine won t be prepended to the generated session name. true is the default, as that was the behaviour in the past. It now can attach to any session, not just the ones it created itself, thus nearly entirely removing my need of ever calling tmux directly. And cosmetically - window names for sessions defined in the .tmux.d directory are no longer plain Multisession , but the session name as defined in the file. If you are interested, you can get it over here from my git repository of misc stuff

Just a small update for those that use my little tmux helper: You may want to fetch the latest version from my git repository. At least if you have to deal with a tmux version prior to 1.4 (like, on squeeze), though I really recommend to use a later one. 1.6 from backports or 1.7 (but thats not backported). Fix is small, just a better handling of the non-existing -V option to get the version information.

As most people that are using that funny grey on black thing with the blinking white box AKA a commandline, I do have a heavily configured shell. zsh in my case. Some while ago my old configuration for it started to annoy me and so I set out to redo it. With the basic requirement to be flexible and able to adjust to various zsh versions (back as far as Lenny). I ve set out and looked how others do it and took the (I hope) best bits and put them together in a way I like it. Maybe others want to pick from me, so here I describe a little, maybe someone is interested First - the config is completly inside .zsh. The only thing directly in my $HOME is a symlink from $HOME/.zshenv to $HOME/.zsh/zshenv.home. All in one place, nicer this way. The zshenv just sets ZDOTDIR, so zsh then uses the .zsh itself. Next I am using modules . Well, actually everything is splitted out in small(er) files, so its way easier to maintain. And to overwrite stuff wherever I need to. So my .zshrc just loads those module files - and then goes and checks if it finds the same file inside a series of subdirectories. Those subdirectories are based on the hostname, the kernel name, the username, the domain name and the name of the distribution of the system. And a number of combinations of those. That system allows me, for example, to have a set of aliases defined only on Debian systems (like those to do with apt-get & co). Or define some extra variables if I login to the host franck, domain debian.org. Or whatever more. I m also on the way of doing something similar for all my dotfiles. While I was working at that I finally got fed up with the fact that my prompt, which is based on Phil! s wasn t doing what I wanted it on various of the hosts I access. Thankfully someone pointed me at a change to the grml zsh config: Frank Terbeck rewrote their prompt to make use of the zstyle system. Now that got me going, I like the idea of having the whole prompt easily configurable and changeable. My prompt always has shown slight differences depending on where the shell runs, which meant I had to carefully craft PS1 for every such change, and when one changes something one had to check all the places to adjust them too. No longer. I took Franks work and extended it for me. I wanted to still have a design matching my old prompt (minus colors, I changed color themes anyways), but with full flexibility the zstyle system can offer here. Now I am at a point where

• One zstyle call can change the information or order in my prompt.
• The prompt automagically leaves out information when the terminal width gets under a limit,
• I can have whatever extra information items in the prompt, even if the prompt never defined a default for it. Including running neccessary functions to update those extra items.
• the prompt switches between color and black/white mode with one zstyle change,
• the prompt draws lines differently, depending on the capabilities of the terminal.

As an example, on the ftp-master host my prompt, while otherwise being the same as everywhere else, contains one extra item - displaying the current status of the archive (dinstall). If you want to try it, the setup file is available, but note that I don t give any warranty. :) Works for me . I load it in my Prompts module, while having the prompt setup file in my function path. The 4 commented lines, my testcase, are a nice example of a custom token, though a real life one, the setup for the ftp-master prompt with the one extra item can be found over here. Comments? Bugfixes? Enhancements? Update: Got asked for an example how to use my prompt to fake another. So here is what you need to do to use my prompt setup to imitate the prompt clint, as delivered with zsh:

autoload promptinit && promptinit
zstyle ':prompt:ganneff' vcs_info true
# Alternatively you can set whatever you like it to be.
zstyle ':prompt:ganneff' set_vcs_info_defaults true
zstyle ':prompt:ganneff' colors true
## no right prompt
zstyle ':prompt:ganneff:right:setup' use-rprompt false
## color of brackets depending on variable
zstyle ':prompt:ganneff:*:items:openbracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:openbracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:closebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:closebracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:openanglebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:openanglebracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:closeanglebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:closeanglebracket' post '$ PR_NO_COLOR '
## extra date format, and its color
zstyle ':prompt:ganneff:*:items:date' token '%D %a %y/%m/%d %R %Z '
zstyle ':prompt:ganneff:*:items:date' pre '$ PR_CYAN '
## pts. %l instead of %y, also color again
zstyle ':prompt:ganneff:*:items:pts' token '%l'
zstyle ':prompt:ganneff:*:items:pts' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:pts' post '$ PR_NO_COLOR '
## host ends with :
zstyle ':prompt:ganneff:*:items:host' token '%m:'
## and a different style for the rc level
zstyle ':prompt:ganneff:*:items:rc' token '%(?..[%?%1v] )'
zstyle ':prompt:ganneff:*:items:rc' pre ''
## change color for other parts that differ to my default
zstyle ':prompt:ganneff:*:items:user' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:host' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:at' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:path' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:history' pre ''
## Show the shell level in a different way
zstyle ':prompt:ganneff:*:items:shell-level' pre ''
zstyle ':prompt:ganneff:*:items:shell-level' token 'zsh%(2L./$SHLVL.) '
## And history is just a bold number. Lazy here, not using pre and post
zstyle ':prompt:ganneff:*:items:history' token '%B%h%b '
## And the last part in prompt, a # or % depending on privileges
## Using standard zsh tokens for bold
zstyle ':prompt:ganneff:*:items:privileges' pre '%B'
zstyle ':prompt:ganneff:*:items:privileges' post '%b'
## Now there are two parts not defined by default, so lets create them
## Both are simple existing variables, no need for extra precmd functions
## system info
zstyle ':prompt:ganneff:extra:ostype' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:ostype' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:ostype' token "$ MACHTYPE /$ OSTYPE /$(uname -r)"
## zsh version
zstyle ':prompt:ganneff:extra:zshvers' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:zshvers' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:zshvers' token "$ ZSH_VERSION "
zstyle ':prompt:ganneff:left:full:setup' items \
    openbracket date closebracket openbracket pts closebracket openbracket ostype closebracket \
    openbracket zshvers closebracket newline openanglebracket user at host \
    path closeanglebracket newline \
    shell-level space history rc space vcs privileges space
prompt ganneff

And if you now tell me Uh, thats so much more than just saying /prompt clint/ , then you are right. But then: This way is flexible. As I wrote above, my prompt on the ftpmaster host is different. Actually, my prompt on all machines inside the domain debian.org differs, by having

zstyle ':prompt:ganneff:*:items:host' pre '$ PR_YELLOW '

in the Prompts definition for domain:debian.org. And thats enough to show me im on a .debian.org machine by a yellow hostname, instead of my default red. On the ftpmaster host I have the additional few lines: # Want one more piece in my prompt here, dinstall status zstyle :prompt:ganneff:left:full:setup items \ ulcorner line openparentheses user at host pts closeparentheses line history \ line dinstall line shell-level line flexline openparentheses path closeparentheses line urcorner newline \ llcorner line rc openparentheses time closeparentheses line vcs line change-root pipe space

zstyle ':prompt:ganneff:extra:dinstall' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:dinstall' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:dinstall' token '$DINSTALL'
zstyle ':prompt:ganneff:extra:dinstall' precmd jj_update_dinstall
zmodload zsh/mapfile
jj_update_dinstall ()  
    DINSTALL="$ $ (z)$ (f)mapfile[/srv/ftp.debian.org/web/dinstall.status] [2] [3,99] "
 

And woo, thats simple. I think. (There ought to be a way to just easily add the item at a defined place in the items zstyle, but meh, too lazy to look).

So this weekend was removal time, namely Lenny. I started out by getting all the different archives which had a Lenny release placed onto archive.debian.org, namely volatile, backports, security and of course the main archive. Actually, they got put onto one of the two hosts that hold this archive and are now syncing to the other. Today started by removing Lenny from those archives. As volatile is dead as an extra archive that was easy - DSA turned off the machine. Backports and security got all their files removed in one big removal after which I had them forget they ever dealt with Lenny. The main archive is a different story. Due to its size I can t simply remove all files at once. This would break every mirror, as they don t delete too many files at once. For the official mirror scripts that magic number is 40000. Both, backports and security, had less than that for their lenny suites, but the main archive has somewhere around 195k files that need to go away. Slightly more than the limit. For that reason I set out to only delete parts of the files for each mirror push. Lucky our toolset supports this easily, I simply had to declare the lenny suites empty and let our clean-suite tool do its work. Worked flawlessly - if one considers 8 hour runtime to mark the files as delete-able no flaw. Took another two hours to actually delete the first 20000 files out of our pool. The next mirror push will thus delete every lenny related entry in our dists/ tree and some 20000 files out of pool. The following mirror pushes will continue deletion, in batches of 10000, until all of lenny is gone.

By now I am a long time happy user of tmux instead of screen. I started using it somewhere in 2011 and by now I only have one usage of screen left over (direct ttyS0 access for one serial). As usual I have a custom config for it, and if you are interested there is a link for you: tmux.conf. But the more interesting part and why I blog is that I also wrote a little helper around tmux. Ingeniously called tm. And a colleague said I should let other people use it too and place it somewhere accessible. So, err, here it is. Or better, the usage output of it, the actual script has a link somewhere below.

---

tmux helper by Joerg Jaspert <joerg@ganneff.de>
Call as: tm CMD [host]...
CMD is one of
 ls          List running sessions
 s           Open ssh session to host
 ms          Open multi ssh sessions to hosts, synchronizing input
 $anything   Either plain tmux session with name of $anything or
             session according to TMDIR file
TMDIR file:
Each file in $TMDIR defines a tmux session.
Filename is the commandline option $anything
Content is defined as:
  First line: Session name
  Second line: extra tmux options
  Any following line: A hostname to open a shell with in the normal
  ssh syntax. (ie [user@]hostname)
Environment variables recognized by this script:
TMPDIR - Where tmux stores its session information
         DEFAULT: If unset: /tmp
TMSORT - Should ms sort the hostnames, so it always opens the same
         session, no matter in which order hostnames are presented
         DEFAULT: true
TMOPTS - Extra options to give to the tmux call
         Note that this ONLY affects the final tmux call to attach
         to the session, not to the earlier ones creating it
         DEFAULT: -2
TMDIR  - Where are session information files stored
         DEFAULT: $ HOME /.tmux.d
TMWIN  - Where does your tmux starts numbering its windows?
         This script tries to find the information in your config,
         but as it only checks $HOME/.tmux.conf it might fail.
         So if your window numbers start at anything different to 0,
         like mine do at 1, then you can set TMWIN to 1

---

It is mainly useful for using tmux as a ssh-multiplexer and replacement for clusterssh though its happy to do any other tmux session too. As the help text may already have told you, you can use it to list existing tmux sessions (oh, wow!). Honestly, that one is there because tm ls is shorter than tmux ls More interestingly, tm s HOSTNAME opens a tmux session with the first window being a ssh shell to HOSTNAME. Should you later type tm s HOSTNAME again, it will attach to the existing session. But the real kicker for me (and colleagues) actually is the ms subcommand of it. ms being short for multi-session, it is my way of no-longer using clusterssh. Basically you type tm ms HOST1 user@HOST2 and it opens a session with one tmux window consisting of two panes. Showing you host1 and host2 at the same time. And the input to both is synchronized, that is - all your input is send to both of them. You aren t limited to just two hosts, do as many as you wish. Actually, I have no idea if tmux has an upper limit, but I did already have more than 100 hosts open at once. The major limitation there is not tmux - but simply the available screenspace, as all hosts are shown in ONE window! (The one advantage of clusterssh, it uses one xterm per host) This is quite helpful in all kinds of administration work involving clusters - imaging installing a package on 5 hosts of a cluster, you usually want it on all of them - or any kind of situations where one wants to run one command on many systems. As I m already said, I m lazy. And so there is a way to easily define multisessions that one uses regulary, by creating files inside the directory behind $TMDIR, usually $ HOME /.tmux.d. They are simple text files and let you easily define sessions you can then (re)open with a simple tm whateveritsname. And if you want the whole script by now: tm

While going through the NM Process, I spent a lot of time on https://nm.debian.org. At the bottom of the page, there is a TODO list of some new features they would like to implement. One item on the list jumped out at me as something I was capable of completing: IRC bot to update stats in the #debian-newmaint channel topic. I immediately reached out to Enrico Zini who was very supportive of the idea. He also explained how he wanted to expand on that idea and have the bot send updates to the channel whenever the progress of an applicant changes. Thanks to Paul Tagliamonte, I was able to get my hands on a copy of the nm.debian.org database (with private information replaced with dummy data). This allowed me to create some code to parse the database and create counts for the number of people waiting in the various queues. I also created a list of events that occurred in the last n days. Enrico then took this code and modified it to integrate it into the website. You can specify the number of days to show events for, and even have the information produced in JSON format. This information is generated upon requesting the page, so it is always up-to-date. It took a couple of rounds of revisions to ensure that the website was exposing all of the necessary information in the JSON export. At this stage, I converted the code to be an IRC bot. Based on prior experience, I decided to implement this as an irssi5 script. The bot is currently running as nmbot in #debian-newmaint on OFTC. Every minute, it fetches the JSON statistics to see if any new events have occurred. If they have, it updates the topic and sends announcements as necessary. While the bot is running, there are still a few more things on its TODO list. First, we need to move it to a stable and permanent home. Running it off of my personal laptop is fine for testing, but it is not a long term solution. Luckily, Joerg Jaspert (Ganneff) has graciously offerred to host the bot. He also made the suggestion of converting the bot to a Supybot plugin so that it could be integrated into the existing ftpmaster bot (dak). The bot's code is currently pretty simple, so I do not expect too much difficulty in converting it to Python/supybot. One last item on the list is something that Enrico is working on implementing. He is going to have the website generate static versions of the JSON output whenever an applicant's progress changes. The bot could then fetch this file, which would reduce the number of times the site needs to generate the JSON. The code for the bot is available in a public git repository, and feedback/suggestions are always appreciated.

Monthly DPL bits, fresh from the oven.

---

Tip to feel good about the release #476: before reading this, grab and fix one of the RC bugs affecting Wheezy. Done? Now you're ready for a slightly less exciting report of DPL activities. Highlights

• I've wrapped up a couple of years of discussions with FSF representatives, proposing a joint working group on FSF' assessment of Debian Free-ness. Some news coverage ensued. The discussion list that has been set up welcomes participants and, in particular, could use some more DDs, fond of Debian principles but also interested in external review of our free/non-free separation.
• DebConf12 has happened!, and many of us attended it. Due to family reasons I've been able to attend only DebCamp and DebConf day-0, just in time to deliver the traditional "bits from the DPL" speech. Among other topics, in the speech I've discussed governance scaling issues in our governance, and in particular about the role of the DPL --- issue which I'm partly trying to address with the "DPL helpers" initiatives. Slides and videos of the talk are available. As many others DebConf people, I took part in Nicaraguan TV shows about DebConf, showing a good deal of interest by the local media in our presence. I don't have links to the recordings yet, but I suspect DebConf orga people will provide them as soon as they're available.
• Many others DebConf12 events are relevant for future Project directions. I went through many of the events I've missed thanks to the work of the video team and of the gobby note takers. I recommend doing the same. Some events are particularly relevant to recent project-wide discussions, such as EFI, hijacking, and the release process and I'm sure you'll find more If you're a DebConf12 speaker and produced slides, please upload them to penta, so that they could be used as future reference.

Assets

• On the hardware front, we bought another server according to DSA's "5-year plan". It will be used as a ganeti node at the man-da hosting location. We bought it thanks to donated money, for a total of ~6'600 EUR.
• (After ~8 months of pestering,) we got from SPI a data dump of Debian financial transactions there. Thanks for this result goes to the SPI Board and in particular to Robert Brockway and Joerg Jaspert. This was the last blocker to produce detailed financial reports for the past couple of years of Debian activities. Unfortunately, it still is a blocker: Debian auditors found out that the data dump is not complete. SPI will send us remaining data soon , but I don't have an ETA, unfortunately.
• An ftpmasters sprint is being organized and I've been happy to approve its budget. Help is still needed on the -sprints list to keep up with the organization part of sprints, including activities like documenting sprints to show donors what we do with their help.

Logo & trademark

• to stop the absurdity of not using the official logo ("with Debian") as part of our official theme, I advanced a bit on the topic of relicensing the logo under a DFSG-free license. I sought a second legal advice to SFLC (as requested by the SPI board). They confirm we can safely do the relicensing (without undermining our rights on contained marks) under a license like dual LGPLv3+ / CC-BY-SA, provided that a suitable trademark policy is in place
• which is why I've posted to -project a trademark policy draft, based on legal advice from SFLC. I've gather useful feedback already, but more is welcome. Note that, as Russ very eloquently put it, we do not particularly enjoy thinking about which restrictions we put on the usage of our marks. But given we do have (and use) those marks, we should better empower the legal owners (SPI in this case) to properly defend them. Our specification for the policy to SFLC has been "as free as possible", and that is what we're trying to achieve.

Note that the actual logo relicensing should be done by SPI, via their board, upon request of mine (as Debian Project liaison). We won't make it for the next SPI board meeting, as it is on 4 days away. But we can aim for the subsequent meeting, on September 13th. If all goes well (big "if"), we will enjoy a DFSG-free logo after that date. Internal organization Recent flurry of re-organization in the tech-ctte --- which I somewhat triggered pushing for periodic meetings --- seems to be proceeding well. I'm very happy about it, as we all need to trust that tech-ctte decisions will be not only sound, but also prompt. If you're interested into this topic, some recent evidence of the ongoing reorganization and its result can be found in their DebConf12 BoF, minutes of the last meeting, a set of forthcoming GRs, and the recent great decision of posting decisions results to d-d-a (as it happened for node/nodejs). Kudos to tech-ctte members for the recent activism! I haven't worked on it myself directly, but I highlight Enrico's work on server side archival of NM conversations. It has the potential of enabling automatic detection of stuck NM processes. I'm a bit rusty as AM now, but I think missing that ability is one of the main remaining causes of frustration when joining Debian. So, if you are an AM, please opt-in and use this feature with your appicants. If you are not an AM why not? Miscellanea Some misc legal stuff:

• I got the legal advice we asked about the possibility of turning mentors.debian.net into an official service. The worry there was about the potential copyright infringements by mentees. In the end, we don't need to worry about that, provided we've clear contact points (and "reasonable" timing ) for removing infringing material once it's been reported, and that we declare our public policy about that. I've a draft policy document to start with. I'll soon contact mentors.d.n to adapt it where needed and have it vetted by SPI before going live.
• I've worked with GNOME maintainers (thanks in particular to Jordi Mallach) to rework the mixed Debian/GNOME logo on their alioth project page, to stay on the safe side and avoid any ambiguity wrt GNOME trademark policy.

and some misc "political" stuff:

• we've been happy to accept an invitation to attend the GNOME Advisory Board meeting at GUADEC: Jord (thanks, again!) kindly accepted to represent Debian there. An early report has been posted on his blog, a more detailed one is forthcoming to -project.
• OSI has discussed with their affiliates the possibility of signing the Declaration of Internet Freedom. On behalf of Debian, I've vouched for it. By the way, I'm serving pro tempore as Debian liaison at OSI, but if there are people interested in doing that, I'll be happy to consider handing over the responsibility to other (it's a quite lightweight one, at present).

Happy RC bug squashing,
Cheers.

---

PS the boring day-to-day activity log for July 2012 is available at master:/srv/leader/news/bits-from-the-DPL.txt.201207

Already chilled by Wheezy freeze? It s been a long ride since the release of Squeeze, and your beloved FTP Team tried to assist our tireless developers and contributors at its best. Here are some hot stats to give you a figure about what happened behind the scenes. Since the release of Squeeze, 7462 .changes files with NEW components were processed by dak, with an average of 14.660 NEW packages per day. On the FTP Team side, we had 6877 accepts (13.511 per day), 641 rejects (1.259 per day) and 280 comments to maintainers (0.550 per day). This table represents the activity by single team member:

Login	Accepts	Rejects	Comments
ansgar	407 accepts (0.800 per day)	71 rejects (0.139 per day)	53 comments (0.104 per day)
dak	12 accepts (0.024 per day)	1 rejects (0.002 per day)	0 comments (0.000 per day)
dktrkranz	4319 accepts (8.485 per day)	381 rejects (0.749 per day)	104 comments (0.204 per day)
joerg	100 accepts (0.196 per day)	12 rejects (0.024 per day)	1 comments (0.002 per day)
mhy	214 accepts (0.420 per day)	14 rejects (0.028 per day)	5 comments (0.010 per day)
stew	67 accepts (0.132 per day)	16 rejects (0.031 per day)	7 comments (0.014 per day)
tolimar	1480 accepts (2.908 per day)	93 rejects (0.183 per day)	84 comments (0.165 per day)
twerner	278 accepts (0.546 per day)	53 rejects (0.104 per day)	26 comments (0.051 per day)

---

Who were the most prolific maintainers who got a NEW processing? Here is our special top ten:

1. Debian Perl Group (559 accepts)
2. Debian Haskell Group (491 accepts)
3. Debian Ruby Extras Maintainers (285 accepts)
4. Debian Java Maintainers (257 accepts)
5. Debian Med Packaging Team (164 accepts)
6. Debian Multimedia Maintainers (160 accepts)
7. Debian Fonts Task Force (156 accepts)
8. Debian Javascript Maintainers (137 accepts)
9. Debian Python Modules Team (129 accepts)
10. Debian Qt/KDE Maintainers (98 accepts)

That doesn t reflect the real developers, though. Here s our Changed-By top ten:

1. Clint Adams (216 accepts)
2. Jonas Smedegaard (208 accepts)
3. Ben Hutchings (203 accepts)
4. Joachim Breitner (153 accepts)
5. TANIGUCHI Takaki (112 accepts)
6. Alessio Treglia (101 accepts)
7. David Paleino (95 accepts)
8. Nicholas Bamber (76 accepts)
9. Mathieu Parent (68 accepts)
10. Jeff Breidenbach (63 accepts)

Clint rocks with tons of Haskell packages, followed by Jonas (mostly Perl packages), and Ben (kernel uploads). Italian cabal stands still, with Alessio and David respectively at 6th and 7th place

---

How long does a package stay in NEW? Some more, some less, but the average is 3 days, 15 minutes and 21 seconds. Now go and check your dak mails to see whether you had a fast processing or not liblog4ada 1.2-1 surely had, as it was accepted after 30 seconds! gsoap 2.7.17-1 was not so lucky, it took 103 days, 8 hours, 20 minutes and 43 seconds to clear NEW, but then made its way to the archive. Better late than never

---

FTP Team is not just accepting NEW packages, but also removing obsolete ones. Here are some details about this task:

• Source packages removed: 2159
• Binaries for architecture all: 8773
• Binaries for architecture alpha: 3646
• Binaries for architecture amd64: 14653
• Binaries for architecture arm: 3
• Binaries for architecture armel: 13283
• Binaries for architecture armhf: 3423
• Binaries for architecture hppa: 1418
• Binaries for architecture hurd-i386: 6923
• Binaries for architecture i386: 15655
• Binaries for architecture ia64: 12365
• Binaries for architecture kfreebsd-amd64: 10972
• Binaries for architecture kfreebsd-i386: 10998
• Binaries for architecture mips: 12478
• Binaries for architecture mipsel: 12479
• Binaries for architecture powerpc: 13945
• Binaries for architecture s390: 12374
• Binaries for architecture s390x: 3884
• Binaries for architecture sparc: 12295

---

FTP Team also took care of override changes:

• Number of priority changes: 853
• Number of section changes: 975

Gnarf. Someone happen to need a new Sysadmin - working from home?

J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager. Raphael: Who are you? J rg: My name is J rg Jaspert and I m 35 years old working for a small company doing system administration and consulting work for our customers. I m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn t think of the movie Alien now is just boring). Raphael: How did you start contributing to Debian? J rg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this lets get a Linux running here came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years. So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one. A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there:

• a signature from a DD on my key (Hi grisu),
• a discussion with an upstream author with some useful piece of software to package and
• an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.

The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL. Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, ). Do you agree that it can be problematic, and if yes, are you trying to scale down? J rg: It s DebConf, tssk. And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved. And looking at those you listed I don t see any I am a SPOF. Let s look at those you listed: DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time. Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages. FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase. And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee. Though we always like new blood and would welcome more volunteers. DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012. Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached. Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his http.debian.net). Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away. Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement? J rg: Oh well, I first met my wife at the International Conference on OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of just doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling Also, she is currently attending a language school having lots of homework in the evening. Gives me time for Debian stuff. How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team? J rg: Bad link, try this one. Also, no longer sounds like its recent. It s not, it s just that people usually recognize the negative only and not the positive parts. Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs. Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out. So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place. Another one is getting the multi-archive stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of merging backports into main it gets an interesting side note when you think of merging security into main . The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often. There is also a discussion about a good way to setup a PPA for Debian service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it. So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package. I don t know exactly where it should end up. Sure, stuff like one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here. Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be? J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past thanks to Mark s work people can now follow the instructions, scripts and whatever they find inside the setup directory. Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw it certainly works and is fun for the one with the chainsaw but you probably end up a little overdoing it. I myself am using dpkg-scan[packages sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough. Also, using dak forces you into some ways of behaviour that are just what Debian wants but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why mentors.debian.net won t work with dak. Or the use of a postgres database. Or that of gpg. Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at. And how should things be : however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to shape Debian by defining limits in terms of who can join and what can be done within Debian? J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:

The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.

Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job. Or a GR against me. Not many running around with that badge, though I m still missing my own personal Serious problems with Mr. Jaspert thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD. Raphael: Is there someone in Debian that you admire for their contributions? J rg: Yes.

---

Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.

I recently got myself a new host somewhere in that big thing internet. Pretty big one too and I m moving stuff from other machines over there, to get rid of the other ones. To have things nicely seperated I am using KVM, especially as I also have many different people owning a VM on that machine. In the past I was using Xen, not KVM, and there was the nice Xen-Shell available for it, so that those other people can manage their own VM, but not need direct access to the main box. Or any kind of root beside the limited ability properly put within the xen-shell. There doesn t seem to be anything like this for KVM. Nothing, nada. What? Oh well, with lots of use of search engines I finally found kvm-shell, a Shell Script from Michael Kress. It looked like it was about to do what I want - except that it didn t work. So I set out last weekend and made it work. So here, for those who are looking for a similar tool, grab your copy from here. The way to use is easy:

• You want to have local users with this script as their shell
• Then add them to a sudoers so they can run virsh
• Party

Any bugs you find (I m sure there are) are yours to keep - or you can send me a mail and a patch. Same for new features, I m interested in getting more stuff in. [Update]: Actually one could name this virsh-shell too. Or libvirt-shell It should work with all systems supported by libvirt, it is just calling virsh $whatever for most of the stuff it does.

Right, so I am at the BSP in Hildesheim. Arrived somewhere Friday, leave in a few hours, and in the meantime I managed to break all our 3 archives at least once. Yay. But heck, I also managed to get them back to work (with help from the FTPTeam too), so it was a good thing. We are back on one code revision for security, backports and main archive. Security also changed to the newer style of handling the buildd repositories and is now also using daks own method of writing packages files instead of using apt-ftparchive. And while I was at it I also created 3 new sections, got a SHA256SUMS file in addition to the MD5SUMS for the debian-installer images (thanks Joeyh for the quick reaction), enabled DM uploads for backports and implemented various other smaller fixes and cleanups.

In my previous blog about Debian's growing archive size I pointed as reference to an hard to read table on the ftp-master server, and missed that the table is not self explanatory and on the first glance hard to read. The table currently looks like the following:

                  e      s     p-u     t      u    t-p-u   l-r    s-u     o    o-p-u   s-r   
---------------------------------------------------------------------------------------------
     all         1096  12034     70  14442  15784     20      1     12   8910    230      0  
    alpha           -      -      -      -      -      -      -      -  13183    297      -  
    amd64        1164  16997    242  18581  19605     39      -     21  13964    342      -  
     arm            -      -      -      -      -      -      -      -  13251    291      -  
    armel         988  16401    239  17879  18680     39      -     21  13411    327      -  
     hppa           -      -      -      -      -      -      -      -  13227    264      -  
  hurd-i386       445      -      -      -  12622      -      -      -      -      -      -  
     i386        1178  17188    242  18727  19751     39      -     21  14377    350      -  
     ia64         951  16036    239  17303  18045     39      -     21  13554    329      -  
kfreebsd-amd64    807  14499    231  15905  16480     39      -     21      -      -      -  
kfreebsd-i386     826  14491    231  15881  16498     39      -     21      -      -      -  
     mips         974  16269    241  17730  18504     39      -     21  13638    323      -  
    mipsel        984  16291    239  17807  18558     39      -     21  13600    319      -  
   powerpc       1078  16677    239  18156  19036     39      -     21  13872    332      -  
     s390        1030  16252    239  17678  18469     39      -     21  13331    327      -  
    source        522  14974     51  16376  17405      1     19      6  12519     75    151  
    sparc         992  16423    239  17895  18673     39      -     21  13542    329      -  

The lines represent different hardware architectures Debian supports, like amd64 (for 64-Bit PCs), i386 (for 32-Bit PCs), etc. Two lines are kind of special, the one marked source and the one marked all. Let's start with the source line: That counts the number of source packages. Those are rarely seen by end users. Source packages contain the actual source needed to build a package, as well as Debian specific changes and a blue print on how to create an actual installable binary package from the source. As you can see Debian supports quite some architectures, which leads to a small problem on the mirrors: Quite a lot shipped in Debian is actually architecture independent. For example documentation, most sound and graphic files, or level data for a game. To avoid storing the very same date multiple times, Debian makes haeavy use of so called arch: all packages. You might have noticed them already while installing them:

Hole:5 ftp://ftp.rrzn.uni-hannover.de/debian/debian/ squeeze/main extremetuxracer-data all 0.4-4 [28,1 MB]
Hole:6 ftp://ftp.rrzn.uni-hannover.de/debian/debian/ squeeze/main extremetuxracer amd64 0.4-4 [273 kB]

In this example I installed a quite small game on the amd64 architecture, which depends on a quite big architecture independent package (notice the all between package name and version) containing it's data.So, to get the actual number of packages a user can install on a specific architecture, one has to add the number in the all line to the number in the specific architecture line. But what column to pick? The columns represent so called suites. The s is for stable, currently Debian 6.0 aka Squeeze and o for oldstable, aka Debian 5.0 Lenny. The t is for testing, aka Wheezy or the upcoming Debian 7.0. The u is for unstable aka sid. The e is for experimental, used for stuff probably not yet ready to be part of a stable release and therefore not uploaded to unstable. The rest is not that interesting (as you see it's mostly empty anyway), like s-u for stable updates, several p-u suites for proposed-updates (that is stuff that might end up in the next point release, and should be tested). And then we have s-r and l-r which I forgot what they are about... Sorry. But back to topic: As I explained briefly a source package is mostly used internally, but may create several binary packages, which a user can install. So the most interesting number for users is the number of binary packages on an arch. So we usually publish this number. So for example, using squeeze on i386 you can install: 17'188 (architecture dependent packages, column s row i386) + 12'034 (architecture independent packages columns s row all) = 29'222 packages. And for completeness: They are build from 14'974 source packages (row source column s). So if look that up for unstable on amd64 you should get to the result 35'389 binary packages build from 17'405 source packages. Slightly less than I reported yesterday, because we removed some old stuff e.g. obsolete libraries in the meantime. Update: J rg just explained me, that the s-r and l-r are there to ensure Debian complies with the GPL. They hold the sources of everything shipped in the original lenny and squeeze releases. Update 2: J rg explained it to me again: s-r and l-r contains sources used without being referenced by a package, and so might get lost otherwise. One example is the kernel used by the debian installation system. You have to boot a kernel somehow, so it can't be packaged. But we still need to save the sources, so it is referenced in these suites and won't get lost.

When Debian squeeze was released in February, it was shipped with slightly less than 30'000 packages. So it was just a matter of time till we also break that border. However, I was quite surprised when I checked the numbers lately and noticed that by now we not only broke the 30'000 packages border but also the 35'000 package! Right now there are 35403 packages available for installation in Debian's unstable branch for the amd64 / 64-Bit-PC architecture! Wow!

OK, this one is meant for Planet Debian...

One of many, many changes in the latest lintian is vendor profiles and, thanks to a heads-up by Niels Thykier, Emdebian will have working profile support in the next upload of emdebian-grip. (The only reason it's not already in Debian is my own fault for not uploading when I thought I had the time to upload.)

$ lintian --profile emdebian-grip drivel_3.0.2-1em1_amd64.deb 

$ lintian --profile debian drivel_3.0.2-1em1_amd64.deb 

E: drivel: debian-changelog-file-missing

E: drivel: copyright-file-compressed

W: drivel: copyright-without-copyright-notice

E: drivel: description-contains-invalid-control-statement

W: drivel: binary-without-manpage usr/bin/drivel

So the em1 version implements Emdebian Policy for Emdebian Grip. Clean for Emdebian Grip, just as the Debian package is clean prior to the changes.

I expect this to dramatically improve the processing of Emdebian packages, both for Grip and for the cross-built flavour, Crush, once that actually starts up.

Thanks to the lintian team for this support. Now if there was some way of backporting this version of lintian to Squeeze, I could also use this at work to suppress really annoying lintian warnings about non-standard suite names. (The whole point of using a non-standard suite name is to keep our stuff separate from the normal Debian/Emdebian stuff for licensing reasons etc.) Update: of course, I didn't check the PTS for lintian before writing that, so hence didn't notice that the backport already exists! Thanks again to Niels for the prompt. I've now got another package to create for work. Update2: Thanks to Joerg Jaspert for the tip that all lintian versions get backported directly from unstable as an exception on ~bpo. The work package is ready, so this is going to make things a lot easier when building stuff on stable.

In other news, the same version of emdebian-grip will include support for integrating Emdebian Grip into Debian itself. This too will use vendor-specific support, this time an internal vendor name which just needs to work on the "buildd".

(It's not quite a buildd, Emdebian Grip doesn't build anything, it's all post-processing. It's just that the processing of Debian packages for Emdebian Grip will look a bit like having a second buildd working on the packages uploaded by the existing buildd. The process itself is still developing...)

During the past Debconf, Joerg borrowed my laptop. I'd told him that he could basically wipe all files if he wanted to, since I had a full backup at home. With that, I mostly meant to say that he could reinstall the box, or add or remove packages as much as he wanted to. What I didn't mean for him to do was to give it back to me with a completely wiped hard disk that it wouldn't even boot off of anymore, but that's what he did. Oh well. So I hadn't done the restore yet, last week, since I'd been busy doing other things. Now, my backup consisted of a file called 'mbr' of 2KB; a file called 'backup.tar.bz2' of 66G, and an LVM volume called 'windows' that was written with 'dd if=/dev/sda1 of=/dev/lvm/windows'[1]. Meaning, I could do a restore, but it was somewhat more involved than just running bacula and allowing it to do its stuff for a while. I briefly considered mounting the external USB disk on which the backup was written to my other laptop, and streaming everything over the network, but quickly discarded that idea for speed issues. Instead, I created 4GB NBD export on that other laptop, ran d-i with my partman-nbd on the to-be-restored laptop, installed Debian to the NBD device, booted off of that, and could then do a restore while having a fully functional system. With the sole gotcha that I couldn't disconnect it from the network until the restore was complete, but that's not insurmountable. The 'dd' restore has finished in the mean time, I'm still waiting for tar to complete its job. Once that's finished, I'll probably have to refresh grub to the internal hard disk, and then I'll be able to boot it. I hope. Having said that, doing a bare-metal restore while booting off of an NBD device is quite practical. I mean, sure, I could have downloaded a live system from the network somewhere, but that would've taken forever, would probably have had an impact on performance of the system while it was running, and overall isn't very ideal IMO. On the other hand, an NBD device is much faster than a local CD or DVD, can be written to without requiring a RAM disk, doesn't need squashfs to get you to reasonable sizes, and as far as the kernel is concerned it's just a local hard disk. If the above paragraph sounds like I'm proud, then that's because I am. Two years ago, doing this would have involved much more manual work. Today, I had a system running root off NBD in minutes. [1] Yeah, so my car has a builtin TomTom GPS that I can't do updates for under Linux, AFAIK. Plus some other stuff. Sue me.

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example. I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again. One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let s proceed with the interview. Raphael: Who are you? Margarita: I m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings. I m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together. I only maintain a handful of packages in Debian, I m more interested in fixing bugs than in packaging new software. I ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina. Raphael: How did you start contributing to Debian? Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG. At some point in 2002/2003 I became a Debian Bug Reporter : most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports. The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved. What happened was that meeting with DDs from all over the world transformed our lives, we became part of the Debian family and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers. The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes. I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life. Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months? Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier s typing efforts when something failed, I was able to experience much of what was discussed. One of the many points that came up during the BOF is that many people Want to help but don t know where to start or how to go about it. It s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through Mini projects or something like that. Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don t know where to start have some sort of general path to follow. Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience? Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution. Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it. I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of. It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations? Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team. During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it. After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made. Raphael: What s the biggest problem of Debian? Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world. Raphael: Do you have wishes for Debian Wheezy? Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more universal with each release, making it more user friendly, more accessible, and more robust than any other previous release. Raphael: Is there someone in Debian that you admire for their contributions? Margarita: I admire a lot of people in Debian. There s a lot of people that contribute a lot of time to Debian, amounts of time that I can t begin to understand how they can afford. I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past. I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely. I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian. And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.

---

Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

14 comments Liked this article? Click here. My blog is Flattr-enabled.